<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>可扩展 3D (X3D), ISO/IEC FCD 19775-1r1:200x, 4 基本概念</title>
<link rel="stylesheet" href="X3D.css" type="text/css">

</head>
<body>

<div class="CenterDiv">
<img class="x3dlogo" SRC="../Images/x3d.png" ALT="X3D logo" style="width: 176px; height: 88px" /> 
</div>

<div class="CenterDiv">

<p class="HeadingPart">
    可扩展 3D (X3D)<br />
    第一部份：架构与基组件</p>

<p class="HeadingClause">4 基本概念</p>
</div>

<IMG class="x3dbar" SRC="../Images/x3dbar.png" ALT="--- X3D separator bar ---" width="430" height="23">

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="General"></a>
4.1 概要</h1>

<h2><a name="Topics"></a>4.1.1 本节主题</h2> 

<P>本节描述了X3D的核心概念，包括X3D场景创作方法及回放原理、X3D场景的运行时(Run-time)定义、通过组件(Component)与Profile进行模块化、支持级别(Level)从而保证一致性(Conformance)、数据编码格式(Data Encoding)、编程途径访问接口和联网情况下的考虑。
</p>

<p><a href="#t-Topics">表 4.1</a> 给出了本节主要内容的链接。</p>

<div class="CenterDiv">

<p class="TableCaption">
<a name="t-Topics"></a>
表 4.1<b> &#8212; </b>主题</p>

<table class="topics">
 <tr> 
  <td> 
   <ul>
    <li><a href="#General">4.1 概要</a> 
     <ul>
      <li><a href="#Topics">4.1.1 主题</a></li> 
      <li><a href="#TopicsOverview">4.1.2 概述</a></li> 
      <li><a href="#Conventions">4.1.3 约定</a></li> 
     </ul></li>
    <li><a href="#Authoring">4.2 创作与回放</a> 
     <ul>
      <li><a href="#X3Dbrowsers">4.2.1 X3D浏览器</a></li> 
      <li><a href="#X3Dgenerators">4.2.2 X3D生成工具</a></li> 
      <li><a href="#X3DLoaders">4.2.3 X3D载入工具</a></li> 
     </ul></li>
    <li><a href="#scenegraph">4.3 场景图</a> 
     <ul>
      <li><a href="#TheSceneGraphOverview">4.3.1 概述</a></li> 
      <li><a href="#Rootnodes">4.3.2 根节点</a></li> 
      <li><a href="#Scenegraphhierarchy">4.3.3 场景图层级</a></li> 
      <li><a href="#Descendantandancestornodes">4.3.4 上下级节点</a></li> 
      <li><a href="#Transformationhierarchy">4.3.5 变换层级</a></li> 
      <li><a href="#Standardunitscoordinates">4.3.6 标准单位与坐标系统</a></li> 
      <li><a href="#Behaviourgraph">4.3.7 行为图</a></li> 
     </ul></li>
    <li><a href="#Runtimeenvironment"> 4.4 运行时环境</a> 
     <ul>
      <li><a href="#RuntimeOverview">4.4.1 概述</a></li> 
      <li><a href="#Objectmodel">4.4.2 对象模型</a> 
       <ul>
        <li><a href="#ObjectmodelOverview">4.4.2.1 概述</a></li> 
        <li><a href="#FieldSemantics">4.4.2.2 域</a></li> 
        <li><a href="#InterfaceHierarchy">4.4.2.3 接口层级</a></li> 
        <li><a href="#Modifyingobjects">4.4.2.4 修改对象</a> 
         <ul>
          <li><a href="#ModifyingObjectsRoutes">4.4.2.4.1 路由</a></li> 
          <li><a href="#ModifyingObjectsViaProgrammaticAccess">4.4.2.4.2 通过可编程途径修改对象</a></li> 
         </ul></li>
        <li><a href="#Objectlifecycle">4.4.2.5 对象生命周期</a></li> 
       </ul></li>
      <li><a href="#DEFL_USESemantics">4.4.3 DEF/USE</a></li>
      <li><a href="#PrototypeSemantics">4.4.4 原型</a> 
       <ul>
        <li><a href="#PrototypeSemanticsIntro">4.4.4.1 介绍</a></li> 
        <li><a href="#PROTOinterfacedeclsemantics">4.4.4.2 PROTO接口声明</a></li> 
        <li><a href="#PROTOdefinitionsemantics">4.4.4.3 PROTO定义</a></li> 
        <li><a href="#Prototypescopingrules">4.4.4.4 Prototype适用范围规则</a></li>
       </ul></li>
      <li><a href="#Externalprototypesemantics">4.4.5 外部原型</a>
       <ul>
        <li><a href="#ExternalprototypeIntro">4.4.5.1 介绍</a></li>
        <li><a href="#EXTERNPROTOInterfaceSemantics">4.4.5.2 EXTERNPROTO接口</a></li> 
        <li><a href="#EXTERNPROTOURLSemantics">4.4.5.3 EXTERNPROTO URL</a></li>
       </ul></li>
      <li><a href="#ImportExportsemantics">4.4.6 导入/导出</a></li> 
      <li><a href="#Runtimenamescope">4.4.7 Run-time name scope</a></li> 
      <li><a href="#Eventmodel">4.4.8 事件模型</a> 
       <ul>
        <li><a href="#Events">4.4.8.1 事件</a></li>
        <li><a href="#Routes">4.4.8.2 路由</a></li>
        <li><a href="#ExecutionModel">4.4.8.3 执行模型</a></li>
        <li><a href="#Loops">4.4.8.4 循环</a></li>
        <li><a href="#Fan-infan-out">4.4.8.5 扇入／出</a></li>
       </ul></li>
     </ul></li>
    <li><a href="#Components">4.5 组件</a> 
     <ul>
      <li><a href="#ComponentsOverview">4.5.1 概述</a></li>
      <li><a href="#DefiningComponents">4.5.2 定义组件</a></li> 
      <li><a href="#Basecomponents">4.5.3 基组件</a></li> 
     </ul></li>
    <li><a href="#Profiles">4.6 Profile</a> 
     <ul>
      <li><a href="#ProfilesOverview">4.6.1 概述</a></li>
      <li><a href="#Definingprofiles">4.6.2 定义Profile</a></li>
	  <li><a href="#RelationshipBetweenProfilesAndComponents">4.6.3 Profile与组件的关系</a></li> 
     </ul></li>
    <li><a href="#Supportlevels">4.7 支持应用级别</a></li> 
    <li><a href="#Dataencodings">4.8 数据编码</a></li> 
    <li><a href="#SceneAccessInterface">4.9 场景访问接口</a></li> 
    <li><a href="#Componentprofilereg">4.10 组件及Profile注册</a></li> 
   </ul>
   <ul>
    <li><a href="#f-X3DArchitecture">图 4.1 &#8212; X3D架构</a></li> 
    <li><a href="#f-Objecthierarchy">图 4.2 &#8212; 对象层级</a></li> 
    <li><a href="#f-ConceptualExecutionModel">图 4.3 &#8212; 概念性执行模型</a></li> 
   </ul>
   <ul>
    <li><a href="#t-Topics">表 4.1 &#8212; 主题</a></li>
    <li><a href="#t-Standardunits">表 4.2 &#8212; 标准单位</a></li>
    <li><a href="#t-RulesmappingPROTOTYPEdecl">表 4.3 &#8212; 映射PROTOTYPE声明到节点实例的规则</a></li>
    <li><a href="#t-ExampleSupportLevelTable">表 4.4 &#8212; 支持级别的实例表格</a></li>
   </ul>
  </td>
 </tr>
</table>
（译者注：authoring这个词的译法在网络上看法不一，是多媒体中的一个概念。通俗一点可以说“编辑”，在多媒体中可以说“制作”，也可以说“开发”。
译者根据author这个词将其译为“创作”，包含了创建、编辑等过程的意思。）
</div>

<h2><a name="TopicsOverview"></a>
4.1.2 概述</h2>

<P>从概念上来讲，每个X3D应用程序是基于时间的三维空间，包含各种机制下都能能被动态修改的图形和听觉对象。 X3D词义中描述了抽象的功能性行为－基于时间、交互式3D、多媒体信息。X3D并未定义物理设备或任何依赖其实现的概念（如屏幕分辨率和输入设备）。 X3D意欲涵盖更宽范围的设备与应用，并提供对功能解释(Interpretation)与实现(Implementation)的足够自由性。比如 X3D甚至都未对鼠标或二维显示设备的存在性作出任何假定。
</P>

<P>每一款X3D应用程序：</P>

<ol start="1" type="a">
  <li>隐式地为所有定义的对象及应用程序中包含的对象构建一个世界坐标系；</li>
  <li>显式定义与渲染一套2D、3D及多媒体对象；</li> 
  <li>能指定指向其它文件或应用程序的超链接；</li> 
  <li>能定义对象行为；</li> 
  <li>通过编程语言和脚本语言可以连接外部模块或应用程序；</li> 
</ol>

<p><a href="#f-X3DArchitecture">图 4.1</a> 为X3D的系统架构。</p>

<p align="center">
&nbsp;</p>
<p class="FigureCaption" align="center">
<b><a name="f-X3DArchitecture"></a></b>
<img src="../Images/X3DArchitecture.png" alt="X3D Architecture"></p>
<p class="FigureCaption" align="center">图 4.1 &#8212; X3D架构</p>
<p>关于构成一个X3D世界的抽象结构的系列陈述，在<a href="components/core.html#AbstractX3DStructure">7.2.5 抽象X3D结构</a>部分。</p>

<h2><a name="Conventions"></a>
4.1.3 约定</h2>

<p>在ISO/IEC 19775这部分的整个内容中所使用的约定如下：</p>

<p><i>斜体</i> 用于域(field)名，同时在新的术语被引入及等式变量被引用时也会用到。</p>

<p>一种<code>等宽</code>字体用于URL地址及源代码实例。</p>

<p>节点类型名要适当大写，如"Billboard节点是一个编组节点..."。然而在要表达这个节点的概念的时候，则经常是小写形式，表示指该节点的语义而不是节点本身，如"为了旋转公告牌(billboard)..."。</p>

<p>"0xhh"这样的形式表示一个字节，这种十六进制数代表该字节的二进制数位配置。</p>

<p>整个ISO/IEC 19775这部分内容中，对国际标准的参考会引用该标准的编号，并在<a href="references.html">2 标准参考说明</a>中给出了该参考的超链接。对本标准各部分的引用由其章节或子章节编号并在后面接上标题组成，并能超链接到所引用的材料内容。对外部非国际标准文档的引用则采用&quot;x.[ABCD]"记号表示，其中"x"表示讲述该参考的章节，"[ABCD]"为参考标题的缩写。<a href="bibliography.html">非标准参考目录</a>中，&quot;x.&quot;被省略了。</p>
<p>另外，子章节中对节点或节点类型的第一次引用会给出到该节点或节点类型定义的超链接。</p>
<p class="Example">示例&nbsp; &quot;2.[ABCD]&quot; 引用<a href="references.html">2 标准参考说明</a>中记录的参考，[ABCD]引用<a href="bibliography.html">非标准参考目录</a>中记录的参考。</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Authoring"></a>
4.2 创作与回放</h1>

<h2><a name="X3Dbrowsers"></a>
4.2.1 X3D浏览器(Browser)</h2>

<p>要X3D文件的解释(Interpretation)、执行(Execution)及再现(Presentation)发生，得使用一种“装置”，即浏览器 - 显示场景图中的造型和声音。这个再现的结果就是生成虚拟世界，并由用户 - 人或机械体在浏览器中进行导航。虚拟世界显示特定位置的场景，该位置的坐标和方位称为浏览者(Viewer)。浏览器可能提供导航模式，比如行走(Walking)或飞行(Flying)，这样就允许用户在虚拟世界中移动浏览者。</p>

<p>除了导航，浏览器还提供一种有限的机制，以使用户在场景图层级中的传感器节点同虚拟世界进行交互。传感器响应用户与虚拟世界中几何体对象的交互，用户在虚拟世界中的移动，或时间的流逝。另外，<a href="references.html#[I19775_2]">该国际标准的第二部分</a>中X3D场景访问接口(SAI)提供了一套机制以获取用户输入，及获取或设置当前视点。浏览者也可以使用SAI以提供用户的导航能力。此外，作者可以使用绑定到SAI的脚本或编程语言来实现他们自己的导航算法。其它的Profile可能指定浏览者所需要的导航能力；这类浏览者通常通过SAI实现。</p> 

<p>X3D虚拟世界中几何对象的可视化再现遵照类似物理光照特性的概念模型。X3D光照模型描述了虚拟世界中生成显示颜色的外观属性与光线的组合方式（查看<a href="components/lighting.html"> 17 光照组件</a>的详细内容）。</p>

<h2><a name="X3Dgenerators"></a>
4.2.2 X3D生成工具(Generator)</h2>

<p>Generator是指X3D文件的人工式或自动式创建工具。Generator负责保证X3D文件的正确性以及能支持在其中引用其它资源，如图片、音频剪辑、其它X3D文件。它还要确保X3D文件中表现的功能，在文件头部已经对Profile、组件和级别信息作了正确的声明。</p>

<h2><a name="X3DLoaders"></a>4.2.3 X3D载入工具(Loader)</h2>

<p>Loader是一套程序，负责载入X3D内容，但不提供任何运行时的内容执行功能。尽管Loader可以自由载入文件及其它远程定义的内容，但场景中几何体不会随时间的前进而发生任何变化。在建模工具中典型的是零时刻(time zero)载入器，用于构建或修改当前X3D内容，而不用在运行时状态来计算。</p>

<p>第二种形式的Loader可以载入文件并运行内容的运行时执行，但它是作为更大的用户界面和三维图形渲染引擎的一部分而实现的。这种Loader可以用于载入如游戏环境中的树这样单独的模型，但X3D内容的运行时计算依赖于外部程序，而不是像X3D浏览器那样自己包含了的。</p>

<h1><a name="scenegraph"></a>
4.3 场景图</h1>

<h2><a name="TheSceneGraphOverview"></a>4.3.1 概述</h2>

<p>场景图是X3D运行时环境的基本单元。这个结构包含了系统中所有的对象及其相互关系。沿着场景图的几条轴线相互关系包含在其中。变换层级描述了渲染对象的空间关系。行为图描述了域(field)与整个系统中事件流程(flow)间的联系。</p>

<h2><a name="Rootnodes"></a>
4.3.2 根节点</h2>

<p>一个X3D文件包含零个或更多根节点。X3D文件的根节点是指那些由节点或USE语句定义的节点，它们未被包含在其它节点或PROTO语句中。根节点应该是<a href="components/group.html">10 编组节点</a>中指定的子式节点，或<a href="components/layering.html#LayerSet">35.4.2 LayerSet</a>中指定的LayerSet节点。</p>

<h2><a name="Scenegraphhierarchy"></a>
4.3.3 场景图层级</h2>

<p>X3D场景图是一种单向非循环图。节点可以包含指定的以一个或更多子式节点作为域值的域，该域下的子式节点即进入了这种层级。这些节点又有可能包含节点（或节点实例）。节点的这种层级就叫做场景图。场景图中每段从A到B的弧意味着A节点有一个域，其值直接包含B节点。层级化场景图的详细资料请查看<a href="bibliography.html#[FOLEY]">[FOLEY]</a>。</p>

<h2><a name="Descendantandancestornodes"></a>
4.3.4 上下级节点</h2>

<p>一个节点的域中所有的节点及这些节点所有的下级节点称为该节点的下级(descendant)。一个节点的上级(ancestor)则指所有将该节点作为下级的节点。</p>

<h2><a name="Transformationhierarchy"></a>
4.3.5 变换层级</h2>

<p>变换层级包含所有根节点及虚拟世界中被认为具有一个或更多特定位置的根节点下级。X3D包含局部坐标系-对从上级坐标系进行坐标变换的定义的术语。显示根节点的坐标系叫做世界坐标系。</p>

<p>X3D浏览器的任务就是将X3D文件的内容展现给用户；它通过表现出这种变换层级关系给用户来实现。变换层级描述了虚拟世界中能直接看得到的部分。</p>

<p align="left">一些节点如传感器和环境节点，也在场景图中，但不受变换层级的影响。包括<a href="components/interp.html#CoordinateInterpolator">CoordinateInterpolator</a>，<a href="components/scripting.html#Script">Script</a>，<a href="components/time.html#TimeSensor">TimeSensor</a>及<a href="components/core.html#WorldInfo">WorldInfo</a>。</p> 

<p>一些节点如<a href="components/group.html#Switch">Switch</a>或
<a href="components/navigation.html#LOD">LOD</a>，包含一个子列表，而在渲染期间多数情况下只有其中之一被遍历。尽管如此，为了计算场景位置，所有这些节点的子节点被认为是变换层级的一部分，而不管在渲染时它们有没有被遍历。例如，一个<a href="components/navigation.html#Viewpoint">Viewpoint</a>节点，它是作为Switch的子节点的，而Switch的whichChoice域被设为-1 - 表示渲染时不使用任何子节点，这时Viewpoint它仍然使用局部坐标空间来确定它在场景中的位置。</p> 

<p>变换层级应是一种单向非循环图。变换层级中的某个节点如果是它自己的上级，则被认为是无效的，且应被忽略。以下就是一个例子：</p>
<pre class="listing">DEF T Transform {
    children [
       Shape { ... }
          USE T
    ]
}     </pre>
<h2><a name="Standardunitscoordinates"></a>
4.3.6 标准单位与坐标系统</h2>

<p>ISO/IEC 19775将世界坐标系的测量单位定义为米。其它所有的坐标系都是基于世界坐标系进行变换。
<a href="#t-Standardunits">表 4.2</a> 列出了ISO/IEC 19775中采用的标准单位。</p>

<div class="CenterDiv">

<p class="TableCaption">
<a name="t-Standardunits"></a>
表 4.2 &#8212; 标准单位</p>

  <table>
   <tr> 
      <th>类别</th>
      <th>单位</th>
    </tr>
    <tr> 
      <td>线性距离</td>
      <td>米</td>
    </tr>
    <tr> 
      <td>角度</td>
      <td>弧度</td>
    </tr>
    <tr> 
      <td>时间</td>
      <td>秒</td>
    </tr>
    <tr> 
      <td>色彩空间</td>
      <td>RGB ([0.,1.], [0.,1.], [0.,1.])</td>
    </tr>
  </table>
</div>

<p>ISO/IEC 19775采用笛卡尔右手三维坐标系。默认情况下，正对屏幕的方向即为Z轴，浏览者在Z轴上透过原点望向-Z轴，+X轴在屏幕右边，+Y在屏幕垂直向上方向。造型成型过程中的变换（查看<a href="components/group.html">10 编组组件</a>中的<a href="components/group.html#Transform">Transform</a>节点定义与<a href="components/navigation.html">23 场景导航组件</a>中的<a href="components/navigation.html#Billboard">Billboard</a>节点定义）或浏览过程中的变换（查看<a href="components/navigation.html">23 场景导航组件</a>中的<a href="components/navigation.html#X3DViewpointNode">X3DViewpointNode</a>节点定义）可用于改变这种默认的投影方式。</p>

<h2><a name="Behaviourgraph"></a>
4.3.7 行为图</h2>

<p>X3D事件模型允许声明域（路由）与模型之间的联系，以便事件沿着那些联系继续传播。行为图即为这些域间联系的汇集，它可以重组路由、添加或终止联系的方式动态更改。通过顺序定义良好的行为图，事件被注入系统并传播。</p>

<p>除非组件支持对此规则的扩展，否则域只能与其它具有相同数据类型的域进行路由。</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Runtimeenvironment"></a>
4.4 运行时环境</h1>

<h2><a name="RuntimeOverview"></a>
4.4.1 概述</h2>

<p>X3D运行时环境维持场景图的当前状态，渲染所需的场景，接收从各种源如传感器的输入，并响应行为系统的指示执行场景图的变化。X3D运行时环境管理对象的生命周期，包括内置对象及用户定义的对象与程序脚本。运行时环境安排事件的处理，这是X3D中生成行为的原始方式。运行时环境也管理X3D浏览器和主机程序间的协调，如文件传输、超链接、页面整合及外部程序访问。</p>

<p>运行时环境管理对象。X3D支持很多类型的内置对象，包括运行时环境中通常有用的功能。有些内建对象用来描述如SFVec3f - 三维矢量值、几何节点如Cylinder及节点之间路由的数据结构。每一个节点包括零或多个域 - 用来存储数据值，及/或包括零或多个事件 - 以在对象间发送或接收事件。文件中进行了声明或使用运行时程序代码的节点会被实例化。作者使用原型机制可以创建新的节点类型（查看 <a href="#PrototypeSemantics">4.4.4, 原型语法</a>）。这些节点成为运行时环境的一部分，并与内置节点表现完全一样。新节点，可通过文件内的原型声明，或在单独位置中引用的外部原型，或运行时环境自身提供的内建原型来创建。原型仅用于创建其它节点，而不是域或路由。</p> 

<p>X3D运行时环境中，事件是生成行为的原始方式。事件的使用贯穿整个X3D：驱动基于时间的动画；处理对象拾取；检测用户的移动和碰撞；改变场景图层级。运行时环境管理事件在系统中的传播及规则定义良好的计算顺序。</p>

<p>X3D内容的作者可以进行场景的创建与管理、渲染、行为及媒体资源的加载。也可控制所创建扩展的载入与合并，这些扩展在X3D或外部语言中编写。内容定义扩展能力由支持原型机制的Profile提供。 </p>

<h2><a name="Objectmodel"></a>
4.4.2 对象模型</h2>

<h3><a name="ObjectmodelOverview"></a>
4.4.2.1 概述</h3>

<p>X3D系统由被称为对象的抽象独立实体构成。ISO/IEC 19775这部分定义了每种对象类型的功能性规范，但并未规定其实现方法。对象的一致性实现应该是依据它的功能性规范的，即<a href="fieldsDef.html">5 域类型参考</a>、7至40章描述的组件、ISO/IEC 19775的第二部分和本标准附加部分定义的对象、域、节点类型。X3D作者通过使用<a href="references.html#[I19776]">ISO/IEC 19776</a>中描述的X3D编码或将来的编码格式，或在运行时使用内置脚本(要看Profile是否提供相应支持)，或通过对场景图使用其它程序访问形式(查看 <a href="references.html#[I19775_2]">ISO/IEC 19775第二部分</a>)，来安排对象。</p>

<p>描述如数据存储与那种类型数据操作等轻量级概念的对象被为域，来自<a href="fieldsDef.html#X3DField">X3DField</a>对象。描述更多完整的空间或时间处理概念的对象称为节点，来自<a href="components/core.html#X3DNode">X3DNode</a>对象。节点包含一个或更多“持有”数据值或为该节点发送/接收事件的域。</p>

<p>通过描述通用属性或功能如可视化对象或组节点的包围盒的接口，或描述元数据的特殊对象，一些节点实现了额外的功能。另外，X3D还定义了用来访问场景图信息的对象类型，这些对象未存储在域或节点中，如路由、原型声明、组件/Profile信息与虚拟世界元数据。</p>

<p>域可以包含给定类型的单个值或该类型的一个数组。本文档中，包含那个指定类型单一值的域类型使用字符SF做前缀，如域a为SFVec3f类型；当域包含数组时，类型名使用字符MF做前缀，如域b为MFVec3f类型。通过使用SFNode和MFNode域类型，域可以包含一个或更多节点。</p>

<p>每个对象都具有如下的通用特征：

<ol type="a">
  <li><b>类型名。</b> 如包括 SFVec3f、MFColor、SFFloat、<a href="components/group.html#Group">Group</a>、<a href="components/enveffects.html#Background">Background</a>或<a href="components/lighting.html#SpotLight">SpotLight</a>等。</li>  
  <li><b>实现。</b> 每个对象的实现对如何对其属性值的变化作出反应、这些变更的结果改变哪些其它属性值及如何影响运行时环境的状态进行了定义。ISO/IEC 19775这部分定义了内置节点的功能性语法，比如由X3D浏览器提供的节点的实现。</li>
</ol>

<p>继承自X3DNode的对象具有以下的额外特征：</p>

<ol type="a" start="4">
  <li><b>零或多个域值。</b> 域值随同节点或域储存在X3D文件中，对虚拟世界的状态进行编码。</li>  
  <li><b>可以接收或发送的零或多个事件。</b> 每个节点可以接收事件到它的域，这会导致节点状态的改变。每个节点从它的域生成事件报告节点状态的变化。从一个节点生成的事件可以连接到其它节点的域以传播这种变化。通过文件中的路由声明或通过SAI服务引用，这种传播得以实现。</li> 
  <li><b>名称。</b> 在文件中使用DEF语句或在运行时通过SAI服务的调用(Call)可以进行节点的命名。这用于其它语句引用指定的节点实例。也可用于场景层级中指定名称节点的定位。</li>
</ol>

<p>节点的实现来自两个源，内置节点与原型。内置节点指由适用的Profile及/或组件声明中指定的可用节点。不同的组件定义了不同的内置节点集。</p>

<p>另外，利用原型，X3D支持内容扩展。原型是作者使用PROTO或EXTERNPROTO语句创建的对象。这些对象以与场景图中描述节点相同的声明符号编写。它们向系统中添加新的对象类型，其只在这些原型被载入的会话的生命周期内可用。一些Profile可能不包括这些扩展能力的支持。原型的语法在<a href="#PrototypeSemantics">4.4.4, 
  原型</a>及<a href="#Externalprototypesemantics">4.4.5, 外部原型</a>中讨论。</p>

<p>原型和内置节点采用相似机制进行实例化。对象可通过预先声明，或在运行时使用<a href="references.html#[I19775_2]">ISO/IEC 19775第二部分</a>中指定的SAI服务进行实例化。所有原型继承自节点基类型<a href="components/core.html#X3DPrototypeInstance">X3DPrototypeInstance</a>。</p>

<h3><a name="FieldSemantics"></a>
4.4.2.2 域</h3>

<P>域定义了节点的持续状态，及以事件形式发送或接收的值。X3D支持对节点的域的四种类型的访问：
<ol type="a">
  <li><i>initializeOnly</i>访问，允许内容为该域提供一个初始值，但不允许以后再改变该值；</li>
  <li><i>inputOnly</i>访问，意味着节点可以接收事件以改变其域值，但该域不允许读取其值；</li>
  <li><i>outputOnly</i>访问，意味着节点在域值改变时发出一个事件，但该域不允许被写入值；</li>
  <li><i>inputOutput</i>访问，允许完整的访问该域：内容可以为该域提供初始值，节点接收事件以改变域值，当域值改变时节点发出事件。</li>
</ol>
<P>inputOutput域可以像inputOnly域那样接收事件，也可以像outputOnly域那样生成事件，并可以像initializeOnly域那样存储在X3D文件中。命名为zzz的inputOutput域，可当成inputOnly被用作'set_zzz'，也可当成outputOnly被用作'zzz_changed'。在ISO/IEC 19775中，inputOutput访问域或inputOnly访问域都被统称为输入域，inputOutput访问域或outputOnly访问域被统称为输出域，这些域接收和发送的事件分别被称为输入事件和输出事件。</p>

<p>inputOutput域的初始值即指X3D文件中它的值，值未被指定时则是指节点中包含的默认值。当inputOutput域接收到事件时，会生成具有相同的值和时间戳的事件。按照优先顺序，以下的材料用于确定inputOutput域的初始值：</P>
<P><!--NOEDIT-->
<OL type=a start="5">
  <LI>节点实例中用户定义的值（在有值被指定的情况下）；
  <LI>节点或原型定义中指定的默认值。</LI>
  </OL><!--/NOEDIT-->
<P></P>
<P>内置节点的initializeOnly域、inputOutput域、outputOnly域和inputOnly域的命名规则建议如下：
</P>
<P><!--NOEDIT-->
<OL type=a start=7>
  <LI>对于包含多个单词的命名，第一个单词首字母小写，其后所有单词的首字母大写，如addChildren，以下说明的set_和_changed除外。</LI>
  <LI>建议所有的inputOnly域使用'set_'前缀，addChildren和removeChildren域除外。</LI>
  <LI>特定类型 - SFTime类型的inputOnly域与outputOnly域不使用"<I>set_</I>"前缀或"<I>_changed</I>"后缀。</LI>
  <LI>建议除了SFBool类型的outputOnly域外，其它所有outputOnly域都附加“_changed”后缀。</LI></OL>

<h3><a name="InterfaceHierarchy"></a>4.4.2.3 接口层级</h3> 

<p>系统中大多数对象类型的一些接口和功能都是从其它对象类型衍生出来的。这些就是我们所知的父类型(supertype)，某个对象即是由父类型衍生而来。同样的，这些父类型可能衍生自其它的对象类型，而形成一个由少量基类型衍生出所有最终对象类型的链。描述系统中所有对象类型相互关系的图称为接口层级(interface hierarchy)。ISO/IEC 19775这部分内容中，对象层级（译者注：从这里开始，出现了两个概念，标题中是接口层级，但主体内容中大都为对象层级，应该是官方的bug）声明了对象间的概念性关系，但没有规定具体的实现方式。
</p>

<p><a href="#f-Objecthierarchy">图 4.2</a> 规定了ISO/IEC 19775所有版本中定义的对象类型的对象层级。在<a href="versionContent.html">附录 L 各版本节点</a>中可以找到对象内容与版本对应关系的规范。</p>
<p class="Example">注意&nbsp; 在特定的组件级别、Profile或版本中，不是所有对象类型都被支持；请参考ISO/IEC 19775这部分内容中单独的组件和Profile声明。</p>

<pre class=diagram><a name="f-Objecthierarchy"></a>      <i>X3DField</i> -+------------- <i>X3DArrayField</i> -+
                +- SFBool                     +- MFBool
                +- SFColor                    +- MFColor
                +- SFColorRGBA                +- MFColorRGBA
                +- SFDouble                   +- MFDouble
                +- SFFloat                    +- MFFloat
                +- SFImage                    +- MFImage
                +- SFInt32                    +- MFInt32
                +- SFMatrix3d                 +- MFMatrix3d 
                +- SFMatrix3f                 +- MFMatrix3f 
                +- SFMatrix4d                 +- MFMatrix4d 
                +- SFMatrix4f                 +- MFMatrix4f 
                +- SFNode                     +- MFNode
                +- SFRotation                 +- MFRotation
                +- SFString                   +- MFString
                +- SFTime                     +- MFTime
                +- SFVec2d                    +- MFVec2d
                +- SFVec2f                    +- MFVec2f
                +- SFVec3d                    +- MFVec3d
                +- SFVec3f                    +- MFVec3f
                +- SFVec4d                    +- MFVec4d
                +- SFVec4f                    +- MFVec4f

<i>      X3DBoundedObject

      X3DFogObject

      X3DPickableObject

      X3DProgrammableShaderObject

      X3DMetadataObject 

      X3DUrlObject 

      X3DNode
</i>        | 
        +- Contact
        +- Contour2D
        +- EaseInEaseOut
        +- GeoOrigin
        +- LayerSet 
        +- MetadataDouble (<i>X3DMetadataObject</i>)*
        +- MetadataFloat (<i>X3DMetadataObject</i>)*
        +- MetadataInteger (<i>X3DMetadataObject</i>)*
        +- MetadataSet (<i>X3DMetadataObject</i>)*
        +- MetadataString (<i>X3DMetadataObject</i>)*
        +- NurbsTextureCoordinate
        +- RigidBody 
        +- ShaderPart (<i>X3DUrlObject</i>)*
        +- ShaderProgram (<i>X3DUrlObject</i>, <i>X3DProgrammableShaderObject</i>)*
        +- TextureProperties
        |
        +- <i>X3DAppearanceNode</i> -+- Appearance
        |
        +- <i>X3DAppearanceChildNode</i> -+- FillProperties
        |                          +- LineProperties
        |                          |
        |                          +- <i>X3DMaterialNode</i> -+- Material
        |                          |                   +- TwoSidedMaterial
        |                          |
        |                          +- <i>X3DShaderNode</i> -+- ComposedShader (<i>X3DProgrammableShaderObject</i>)*
        |                          |                 +- PackagedShader (<i>X3DUrlObject</i>, <i>X3DProgrammableShaderObject</i>)*
        |                          |                 +- ProgramShader
        |                          |
        |                          +- <i>X3DTextureNode</i> -+- MultiTexture
        |                          |                  |
        |                          |                  +- <i>X3DEnvironmentTextureNode</i> -+- ComposedCubeMapTexture
        |                          |                  |                             +- GeneratedCubeMapTexture
        |                          |                  |                             +- ImageCubeMapTexture (<i>X3DUrlObject</i>)*
        |                          |                  | 
        |                          |                  +- <i>X3DTexture2DNode</i> -+- ImageTexture (<i>X3DUrlObject</i>)*
        |                          |                  |                    +- MovieTexture (<i>X3DSoundSourceNode</i>, <i>X3DUrlObject</i>)*
        |                          |                  |                    +- PixelTexture
        |                          |                  |
        |                          |                  +- <i>X3DTexture3DNode</i> -+- ComposedTexture3D
        |                          |                                       +- ImageTexture3D (<i>X3DUrlObject</i>)*
        |                          |                                       +- PixelTexture3D
        |                          |   
        |                          +- <i>X3DTextureTransformNode</i>  +- MultiTextureTransform
        |                                                     -+- TextureTransform
        |                                                      +- TextureTransformMatrix3D
        |                                                      +- TextureTransform3D
        |                                                     
        |
        +- <i>X3DFontStyleNode</i> -+- FontStyle
        |                    +- ScreenFontStyle                              
        |
        +- <i>X3DGeometryNode</i> -+- Arc2D
        |                   +- ArcClose2D
        |                   +- Box
        |                   +- Circle2D
        |                   +- Cone
        |                   +- Cylinder
        |                   +- Disk2D
        |                   +- ElevationGrid
        |                   +- Extrusion
        |                   +- GeoElevationGrid
        |                   +- IndexedLineSet
        |                   +- LineSet
        |                   +- PointSet
        |                   +- Polyline2D
        |                   +- Polypoint2D
        |                   +- Rectangle2D
        |                   +- Sphere
        |                   +- Text
        |                   +- TriangleSet2D 
        |                   |
        |                   +- <i>X3DComposedGeometryNode</i> -+- IndexedFaceSet
        |                   |                           +- IndexedTriangleFanSet
        |                   |                           +- IndexedTriangleSet
        |                   |                           +- IndexedTriangleStripSet
        |                   |                           +- IndexedQuadSet
        |                   |                           +- QuadSet
        |                   |                           +- TriangleFanSet
        |                   |                           +- TriangleSet
        |                   |                           +- TriangleStripSet
        |                   |
        |                   +- <i>X3DParametricGeometryNode</i> -+- NurbsCurve
        |                                                 +- NurbsSweptSurface
        |                                                 +- NurbsSwungSurface
        |                                                 |
        |                                                 +- <i>X3DNurbsSurfaceGeometryNode</i> -+- NurbsPatchSurface
        |                                                                                 +- NurbsTrimmedSurface
        |
        +- <i>X3DGeometricPropertyNode</i> -+- FogCoordinate
        |                            +- HAnimDisplacer
        |                            |
        |                            |+- <i>X3DColorNode</i> -+- Color
        |                            |                +- ColorRGBA
        |                            |
        |                            +- <i>X3DCoordinateNode</i> -+- Coordinate
        |                            |                     +- CoordinateDouble
        |                            |                     +- GeoCoordinate
        |                            |
        |                            +- <i>X3DNormalNode</i> -+- Normal
        |                            |
        |                            +- <i>X3DTextureCoordinateNode</i> -+- MultiTextureCoordinate
        |                            |                            +- TextureCoordinate
        |                            |                            +- TextureCoordinate3D
        |                            |                            +- TextureCoordinate4D
        |                            |                            +- TextureCoordinateGenerator
        |                            |
        |                            +- <i>X3DVertexAttributeNode</i> -+- FloatVertexAttribute
        |                                                       +- Matrix3VertexAttribute
        |                                                       +- Matrix4VertexAttribute
        |
        +- <i>X3DLayerNode</i> -+- Layer
        |                +- LayoutLayer
        |
        +- <i>X3DNBodyCollisionSpaceNode</i> (<i>X3DBoundedObject</i>)* -+- CollisionSpace
        |
        +- <i>X3DNurbsControlCurveNode</i> -+- ContourPolyline2D
        |                            +- NurbsCurve2D
        |
        +- <i>X3DParticleEmitterNode</i> -+- ConeEmitter
        |                          +- ExplosionEmitter
        |                          +- PointEmitter
        |                          +- PolylineEmitter
        |                          +- SurfaceEmitter
        |                          +- VolumeEmitter
        |
        +- <i>X3DParticlePhysicsModelNode </i> -+- BoundedPhysicsModel
        |                               +- GravityPhysicsModel
        |                               +- WindPhysicsModel
        |
        +- <i>X3DProtoInstance</i>
        |
        +- <i>X3DRigidJointNode</i> -+- BallJoint
        |                     +- DoubleAxisHingeJoint
        |                     +- MotorJoint
        |                     +- SingleAxisHingeJoint
        |                     +- SliderJoint
        |                     +- UniversalJoint
        |
        +- <i>X3DChildNode</i> -+- BooleanFilter
                         +- BooleanToggle
                         +- ClipPlane
                         +- CollisionCollection
                         +- DISEntityManager
                         +- GeoLOD (<i>X3DBoundedObject</i>)*
                         +- HAnimHumanoid (<i>X3DBoundedObject</i>)*
                         +- Inline (<i>X3DUrlObject</i>, <i>X3DBoundedObject</i>)*
                         +- LocalFog (<i>X3DFogObject</i>)*
                         +- NurbsOrientationInterpolator
                         +- NurbsPositionInterpolator
                         +- NurbsSet (<i>X3DBoundedObject</i>)*
                         +- NurbsSurfaceInterpolator
                         +- RigidBodyCollection 
                         +- StaticGroup (<i>X3DBoundedObject</i>)*
                         |
                         +- <i>X3DBindableNode</i> -+- Fog (<i>X3DFogObject</i>)*
                         |                   +- GeoViewpoint
                         |                   +- NavigationInfo
                         |                   |
                         |                   +- <i>X3DBackgroundNode</i> -+- Background 
                         |                   |                     +- TextureBackground
                         |                   |
                         |                   +- <i>X3DViewpointNode</i> -+- OrthoViewpoint
                         |                                        +- Viewpoint
                         |                                        +- ViewpointGroup
                         |
                         +- <i>X3DFollowerNode</i> -+- <i>X3DChaserNode</i> -+- OrientationChaser
                         |                   |                 +- PositionChaser
                         |                   |                 +- PositionChaser2D
                         |                   |                 +- ScalerChaser
                         |                   |
                         |                   +- <i>X3DDamperNode</i> -+- ColorDamper
                         |                                     +- CoordinateDamper
                         |                                     +- OrientationDamper
                         |                                     +- PositionDamper
                         |                                     +- PositionDamper2D
                         |                                     +- TexCoordDamper
                         |
                         +- <i>X3DGroupingNode</i> (<i>X3DBoundedObject</i>)* -+- Anchor
                         |                                       +- Billboard
                         |                                       +- CADAssembly (<i>X3DProductStructureChildNode</i>)*
                         |                                       +- CADLayer
                         |                                       +- CADPart (<i>X3DProductStructureChildNode</i>)*
                         |                                       +- Collision (<i>X3DSensorNode</i>)*
                         |                                       +- EspduTransform (<i>X3DSensorNode</i>)*
                         |                                       +- GeoLocation
                         |                                       +- Group
                         |                                       +- HAnimJoint
                         |                                       +- HAnimSegment
                         |                                       +- HAnimSite
                         |                                       +- LayoutGroup
                         |                                       +- LOD
                         |                                       +- PickableGroup (<i>X3DPickableObject</i>)*
                         |                                       +- ScreenGroup
                         |                                       +- Switch
                         |                                       +- Transform
                         |                                       |
                         |                                       +- <i>X3DViewportNode</i> -+- Viewport
                         |
                         +- <i>X3DInfoNode</i> --+- DISEntityTypeMapping
                         |                +- GeoMetadata
                         |                +- WorldInfo
                         |
                         +- <i>X3DInterpolatorNode</i> -+- ColorInterpolator
                         |                       +- CoordinateInterpolator
                         |                       +- CoordinateInterpolator2D
                         |                       +- GeoPositionInterpolator
                         |                       +- NormalInterpolator
                         |                       +- OrientationInterpolator
                         |                       +- PositionInterpolator
                         |                       +- PositionInterpolator2D
                         |                       +- ScalarInterpolator
                         |                       +- SplinePositionInterpolator
                         |                       +- SplinePositionInterpolator2D
                         |                       +- SplineScalarInterpolator
                         |                       +- SquadOrientationInterpolator
                         |
                         +- <i>X3DLayoutNode</i> -+- Layout
                         |                   
                         +- <i>X3DLightNode</i> -+- DirectionalLight
                         |                +- PointLight
                         |                +- SpotLight 
                         |
                         +- <i>X3DNBodyCollidableNode</i> (<i>X3DBoundedObject</i>)* -+- CollidableOffset
                         |                                              +- CollidableShape
                         |
                         +- <i>X3DProductStructureChildNode</i> -+- CADAssembly (<i>X3DGroupingNode</i>)*
                         |                                +- CADFace (<i>X3DBoundedObject</i>)*
                         |                                +- CADPart (<i>X3DGroupingNode</i>)*
                         |
                         +- <i>X3DScriptNode</i> (<i>X3DUrlObject</i>)* -+- Script
                         |
                         +- <i>X3DSensorNode</i> -+- Collision (<i>X3DGroupingNode</i>)* 
                         |                 +- CollisionSensor
                         |                 +- EspduTransform (<i>X3DGroupingNode</i>)*
                         |                 +- ReceiverPdu (<i>X3DBoundedObject</i>)*
                         |                 +- SignalPdu (<i>X3DBoundedObject</i>)*
                         |                 +- TimeSensor (<i>X3DTimeDependentNode</i>)*
                         |                 +- TransmitterPdu (<i>X3DBoundedObject</i>)*
                         |                 |
                         |                 +- <i>X3DEnvironmentalSensorNode</i> -+- GeoProximitySensor
                         |                 |                              +- ProximitySensor
                         |                 |                              +- TransformSensor
                         |                 |                              +- VisibilitySensor
                         |                 |
                         |                 +- <i>X3DKeyDeviceSensorNode</i> -+- KeySensor
                         |                 |                          +- StringSensor
                         |                 |
                         |                 +- <i>X3DNetworkSensorNode</i> +- LoadSensor
                         |                 |
                         |                 +- <i>X3DPickingNode</i> -+- LinePicker
                         |                 |                  +- PointPicker
                         |                 |                  +- PrimitivePicker
                         |                 |                  +- VolumePicker
                         |                 | 
                         |                 +- <i>X3DPointingDeviceSensorNode</i> -+- <i>X3DDragSensorNode</i> -+- CylinderSensor
                         |                                                 |                     +- PlaneSensor
                         |                                                 |                     +- SphereSensor
                         |                                                 |
                         |                                                 +- <i>X3DTouchSensorNode</i> -+- GeoTouchSensor
                         |                                                                        +- TouchSensor
                         |
                         +- <i>X3DSequencerNode</i> -+- BooleanSequencer
                         |                    +- IntegerSequencer
                         |
                         +- <i>X3DShapeNode</i> (<i>X3DBoundedObject</i>) -+- ParticleSystem
                         |                                   +- Shape
                         |
                         +- <i>X3DSoundNode</i> -+- Sound 
                         |
                         +- <i>X3DTimeDependentNode</i> -+- TimeSensor (<i>X3DSensorNode</i>)*
                         |                        |
                         |                        +- <i>X3DSoundSourceNode</i> -+- AudioClip (<i>X3DUrlObject</i>)*
                         |                                               +- MovieTexture (<i>X3DTexture2DNode</i>, <i>X3DUrlObject</i>)*
                         |
                         +- <i>X3DTriggerNode</i> -+- BooleanTrigger
                                            +- IntegerTrigger
                                            +- TimeTrigger

* = 衍生自多个接口</pre>

<div class="CenterDiv">
<p class="FigureCaption">
图 4.2 &#8212; 接口层级</p>

</div>

<p>对象层级定义了抽象的接口，也定义了具体的节点类型。抽象接口定义了继承自其的其它接口及/或节点的功能，但从来不会在场景图中实例化为对象。具体节点类型衍生自一个或多个抽象接口，并可以在场景图中实例化。也就是说，实际的场景图仅由具体节点类型的实例组成。实现抽象接口功能要用到ISO/IEC 19775这部分中定义的组件，只因为那个功能通过衍生于具体节点类型的其中之一所提供。<a href="references.html#[I19775_2]">ISO/IEC 19775 第二部分</a>定义了应用程序通过编程途径访问由抽象接口与具体节点所提供功能的方式。</p>

<p>大多数对象衍生自两种主要的对象类型，它们为<i><a href="components/core.html#X3DNode">X3DNode</a></i>与<i><a href="fieldsDef.html#X3DField">X3DField</a></i>。节点是陈述性语言中用于构成场景图的对象，同时域包含于节点中以存储节点的数据值。一些域对象包含如整型或字符串等简单数据值。其它域对象包含节点引用。X3DNode包含X3DField且X3DField包含对X3DNode的引用，这正是X3D构成场景图层级的机制。</p>
<p class="Example">示例</p>

<pre class="listing">Transform { translation 1 2 3
  children [
    Shape {
      geometry Box { }
    }
    Group {
      children [ ... ]
    }
  ]
}
</pre>

<p class="Example">上面的例子中，Transform节点包含了一个简单域<tt>translation</tt>，其包括了一个三维矢量值。它也包含了一个children域，包含其它节点数组，此例中包含了一个Shape节点和一个Group节点，它们的域中同样也可以包含其它的对象。</p>

<p>衍生机制使得可以对所有对象进行清晰地分类。上面的例子中，children域被限制为包含衍生自叫<i><a href="components/core.html#X3DChildNode">X3DChildNode</a></i>对象类型的系列对象。<a href="components/shape.html#Shape">Shape</a>与<a href="components/group.html#Group">Group</a>都是（非直接）衍生自这个对象，就可以被放到children域中。反之，Shape的geometry域仅能包含衍生自<i>
<a href="components/rendering.html#X3DGeometryNode">X3DGeometryNode</a></i>的单个节点。<a href="components/geometry3D.html#Box">Box</a>也衍生自这个对象，可以被放到geometry域中。但Box却非衍生自<i>X3DChildNode</i>，因此它不能放到children域。同样地，Group不是衍生自<i>X3DGeometryNode</i>，就不能被置于geometry域中。</p>

<p>上面的例子展示了衍生机制的另一项特质。<a href="components/group.html#Transform">Transform</a>衍生自<i><a href="components/group.html#X3DGroupingNode">X3DGroupingNode</a></i>，因而也继承了它的children域。这使得Transform的规范更简单，因为它不再需要描述children域的功能。因为它衍生自<i>X3DGroupingNode</i>，作者就知道它包含了一个children域，其具有与同样衍生自<i>X3DGroupingNode</i>的Group相同的行为。</p>

<h3><a name="Modifyingobjects"></a>
4.4.2.4 修改对象</h3>

<h4><a name="ModifyingObjectsRoutes"></a>4.4.2.4.1 路由</h4>

<p>有很多方式修改对象的域。使用X3D其中的一种文件格式，作者可以声明一套节点集、这些节点的域的初始值及域之间的相互联系即路由。在运行时X3D采用事件传播或数据流(<i>dataflow</i>)模型来更改域的值。作为它的抽象规范的一部分，描述了节点对发送到它的域的事件作出响应的行为，及它的域发出事件的条件。</p>
<p class="Example">示例&nbsp; 仅使用这种事件传播模型就可创建出带有运行时行为的场景：</p>

<blockquote>
	<pre class="listing">DEF TS TimeSensor {
  loop TRUE
  cycleInterval 5
}
DEF I PositionInterpolator {
  key [ 0 0.5 1 ]
  keyValue [ 0 -1 0, 0 1 0, 0 -1 0 ]
}
DEF T Transform {
  children [
    Shape {
      geometry Box { }
    }
  ]
}
ROUTE ts.fraction_changed TO I.set_fraction
ROUTE I.value_changed TO T.set_translation
</pre>
</blockquote>

<p class="Example">这个例子实现了一个盒子的上下弹动，并以每5秒为一个周期重复进行。定义了TimeSensor对象，它的<tt>fraction</tt>域来连续发出事件。这个事件发出了一个由0到1之间的浮点数值，这个值代表<tt>cycleInterval</tt>声明的5秒间隔中的某个时刻。它的<tt>loop</tt>域告诉它要重复进行这个动作。这个fraction值被发送到PositionInterpolator的<tt>fraction</tt>域。PositionInterpolator这个对象被定义为不管何时它的fraction域收到了事件，它的<tt>value</tt>域都发出一个事件。value值由<tt>key</tt>与<tt>keyValue</tt>确定。这个例子中，它发出一个y值在-1到+1间变动且在一个周期结束时又重复的矢量。这个值被发送到Transform节点的<tt>translation</tt>域。定义Transform这个节点用于根据<tt>translation</tt>的值设置它的children内容的位置。
<a href="#Routes">4.4.8.2 路由</a>包含了更多关于路由传播的更多信息。</p>

<h4><a name="ModifyingObjectsViaProgrammaticAccess"></a>4.4.2.4.2 通过可编程途径修改对象</h4>

<p>路由机制简单，但仅限于改变节点域值，且所有的改变都设计在既定的节点集中。为了获得更大的灵活性，系统中一些Profile中提供了编程途径访问对象的能力。这允许域值的设置或读取及函数的调用。还提供了允许发现PROTO对象的机制，从而那种类型的对象可被实例化。</p>

<p>X3D中编程途径访问类型有两种：外部访问，<span class="example">例如从被包含的HTML页面或被嵌入的本地应用程序访问</span>，与内部脚本，即任何被支持的脚本语言。<p>
<p>对对象的编程途径访问通过那些对象的<i>接口</i>提供。对象的接口（它的数据与功能属性设置）以<i>对象类型</i>的形式被声明及引用。描述节点的对象类型还以<i> 节点类型</i>的形式被引用。对象类型可以是抽象的，也可以是具体的。抽象对象类型不能被实例化。它们被用于衍生其他对象类型或声明能包含任何<i>衍生性节点类型</i>节点的域。具体节点类型衍生自那些抽象节点类型，并可实例化。对象接口的一致性实现应该支持<a href="references.html#[I19775_2]">ISO/IEC 197775第二部分</a>中定义的接口规范。</p>

<p>查看<a href="#SceneAccessInterface">4.9, 应用程序编程接口</a>以了解更多信息。</p>

<h3><a name="Objectlifecycle"></a>
4.4.2.5 对象生命周期</h3>

<p>节点有生命周期：创建、使用及最终被销毁。如果符合以下一个或更多条件，节点被认为是“活的”：</p>

<ol type="a">
  <li>场景中的根节点。</li>
  <li>被“活的”节点的某个域引用的节点。</li>
  <li>被“活的”脚本引用的节点。</li>
  <li>被外部程序引用的节点。</li>
</ol>

<p>重复应用规则b与c，覆盖整个“活的”场景图。</p>

<p>文件中的实例由浏览器根据碰到的节点实例或对原型场景图的实例化隐式创建节点。节点也可以由程序访问途径实例化；这种情况下，节点生命周期具有更多额外离散的阶段。参考<a href="references.html#[I19775_2]">ISO/IEC 19775第二部分</a>获得更多细节。</p>

<h2><a name="DEFL_USESemantics"></a>4.4.3 DEF/USE</h2>

<p>节点名称有效范围在单个X3D文件、原型定义，或提交到CreateX3DFromString、CreateX3DFromStream、或CreateX3DFromURL浏览器服务的字符串、在使用 DEF 关键词命名后，可以在同一个文件中用 USE 或 ROUTE 语句引用这个命名的节点。USE 语句不会建立这个节点的副本，而是把同一个节点再次插入场景图，此时一个节点有多个父。多次引用一个节点的实例称为事例化。
Node names are limited in scope to a single X3D file, prototype definition, 
or string submitted to either CreateX3DFromString, CreateX3DFromStream, or 
CreateX3DFromURL browser service or a construction for SFNodes within a script. 
The USE statement does not create a copy of the node. Instead, the same node is 
inserted into the scene graph a second time, resulting in the node having 
multiple parents (see <a href="#Transformationhierarchy">
4.3.5 Transformation hierarchy</a>, for restrictions on self-referential nodes).<br>
<br>
Node names shall be unique in the context within which the associated DEF 
keyword occurs.</p>

<h2><a name="PrototypeSemantics"></a>4.4.4 原型</h2>

<h3><a name="PrototypeSemanticsIntro"></a>4.4.4.1 介绍</h3>

<p>The PROTO statement defines a new node type in terms of already defined (built-in 
  or prototyped) node types. Once defined, prototyped node types may be instantiated 
  in the scene graph exactly like the built-in node types.</p>

<p>Node type names shall be unique in each X3D file. The results are undefined 
  if a prototype is given the same name as a built-in node type or a previously 
  defined prototype in the same scope.</p>

<h3><a name="PROTOinterfacedeclsemantics"></a>
4.4.4.2 PROTO接口声明</h3>

<p>The prototype interface defines the fields and field access types for the 
  new node type. The interface declaration includes the types, names and default 
  values (for initializeOnly and inputOutput fields) for the prototype's fields.</p>

<p>The interface declaration may contain inputOutput field declarations, which are 
  a convenient way of defining an initializeOnly field, inputOnly field,
  and outputOnly field at the same time. 
  If an inputOutput field named <i>zzz</i> is declared, it is equivalent to
  separately declaring an initializeOnly field named <i>zzz</i>, an inputOnly field named <i>set_zzz</i>,
  and an outputOnly field named <i>zzz_changed</i>.</p>

<p>Each prototype instance can be considered to be a complete copy of the prototype, 
  with its own field values and copy of the prototype definition. A prototyped 
  node type is instantiated using standard node syntax. For example, the following 
  prototype (which has an empty interface declaration):</p>

<pre class="listing">PROTO Cube [ ] { Box { } }
</pre>

<p>may be instantiated as follows:</p>

<pre class="listing">Shape { geometry Cube { } }
</pre>

<p>It is recommended that user-defined field names defined in PROTO interface 
  declarations statements follow the naming conventions described in <a href="#FieldSemantics">
  4.4.2.2 Field semantics</a>.
</p>

<p>If an outputOnly field in the prototype declaration is associated with an
  inputOutput field in the prototype definition, the initial value of the
  associated outputOnly field shall be the 
  initial value of the inputOutput field. If the outputOnly field is 
  associated with multiple inputOutput fields, the results are undefined.</p>

<h3><a name="PROTOdefinitionsemantics"></a>
4.4.4.3 PROTO定义</h3>

<p>A prototype definition consists of one or more nodes, nested PROTO statements, 
  and ROUTE statements. The first node type determines how instantiations of the 
  prototype can be used in an X3D file. An instantiation is created by filling 
  in the parameters of the prototype declaration and inserting copies of the first 
  node (and its scene graph) wherever the prototype instantiation occurs.</p>
<p class="Example">EXAMPLE&nbsp; If the first node in the prototype definition is a Material node, instantiations 
  of the prototype can be used wherever a Material node can be used. Any other 
  nodes and accompanying scene graphs are not part of the transformation hierarchy, 
  but may be referenced by ROUTE statements or Script nodes in the prototype definition.</p>

<p>Nodes in the prototype definition may have their fields associated with the fields
  of the prototype interface declaration by using IS statements in the body of the node. 
  When prototype instances are read from an X3D file, field values for the fields 
  of the prototype interface may be given. If given, the field values are used 
  for all nodes in the prototype definition that have IS statements for those 
  fields. Similarly, when an input field of a prototype instance
  is sent an event, the event is delivered to all nodes that have IS statements for that
  field. When a node in a prototype instance generates an output event that has an IS statement,
  the event is sent to any input fields connected (via ROUTE) to the prototype instance's
  output field.</p>

<p>IS statements may appear inside the prototype definition wherever fields may 
  appear. IS statements shall refer to fields defined in the prototype 
  declaration. Results are undefined if an IS statement refers to a non-existent 
  declaration. Results are undefined if the type of the field being associated 
  by the IS statement does not match the type declared in the prototype's interface 
  declaration. For example, it is illegal to associate an SFColor with an SFVec3f. 
  It is also illegal to associate an SFColor with an MFColor or <i>vice versa</i>.</p>

<p>Results are undefined if an IS statement:</p>

<ul>
  <li>inputOnly field is associated with a initializeOnly field or an outputOnly field;</li>
  <li>outputOnly field is associated with a initializeOnly field or inputOnly field;</li>
  <li>initializeOnly field is associated with an inputOnly field or outputOnly field.</li>
</ul>

<p>An inputOutput field in the prototype interface may be associated only with an inputOutput
  field in the prototype definition, but an inputOutput field in the prototype definition 
  may be associated with either an inputOutput field, inputOnly field, or outputOnly field in 
  the prototype interface. When associating an inputOutput field in a prototype definition 
  with an inputOnly field or outputOnly field in the prototype declaration, it is valid to use 
  either the shorthand inputOutput field name (<i>e.g.</i>,<i> translation</i>) or the 
  explicit field name (<i>e.g.</i>,<i> set_translation</i> or <i>translation_changed</i>).
<a href="#t-RulesmappingPROTOTYPEdecl">Table 4.3</a> defines the rules for mapping between 
  the access types of fields in a prototype declarations and the access types for fields in
  its primary scene graph's nodes (<i>yes </i>denotes a legal mapping, <i>no </i>denotes an error).</p>

<div class="CenterDiv">
<p class="TableCaption">
<a name="t-RulesmappingPROTOTYPEdecl"></a>
Table 4.3 &#8212; Rules for mapping PROTOTYPE declarations 
to node instances</p> 

<table>
  <tbody> 
  <tr> 
    <td></td>
    <td><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Prototype 
      declaration</b></td>
  </tr>
  <tr> 
    <td><b>Prototype</b><br />
      <p><b>definition</b></td>
    <td>
      <p> 
      <center>
        <table>
          <tbody> 
          <tr> 
            <td></td>
            <td><b><u>inputOutput</u></b></td>
            <td><b><u>initializeOnly</u></b></td>
            <td><b><u>inputOnly</u></b></td>
            <td><b><u>outputOnly</u></b></td>
          </tr>
          <tr> 
            <td><b><u>inputOutput</u></b></td>
            <td><tt>yes</tt></td>
            <td><tt>yes</tt></td>
            <td><tt>yes</tt></td>
            <td><tt>yes</tt></td>
          </tr>
          <tr> 
            <td><b><u>intializeOnly</u></b></td>
            <td><tt>no</tt></td>
            <td><tt>yes</tt></td>
            <td><tt>no</tt></td>
            <td><tt>no</tt></td>
          </tr>
          <tr> 
            <td><b><u>inputOnly</u></b></td>
            <td><tt>no</tt></td>
            <td><tt>no</tt></td>
            <td><tt>yes</tt></td>
            <td><tt>no</tt></td>
          </tr>
          <tr> 
            <td><b><u>outputOnly</u></b></td>
            <td><tt>no</tt></td>
            <td><tt>no</tt></td>
            <td><tt>no</tt></td>
            <td><tt>yes</tt></td>
          </tr>
          </tbody>
        </table>
      </center>
    </td>
  </tr>
  </tbody>
</table>
</div>

<p>Results are undefined if a field of a node in the prototype 
  definition is associated with more than one field in the 
  prototype's interface (<i>i.e.</i>, multiple IS statements for a field in a node in the
  prototype definition), but multiple IS statements for the fields in the prototype
  interface declaration is valid. Results are undefined if a field of a node in a
  prototype definition is both defined with initial values (<i>i.e.</i>, field statement) and
  associated  by an IS statement with a field in the prototype's interface. If a prototype 
  interface has an outputOnly field <i>E</i> associated with multiple outputOnly fields in the 
  prototype definition 
<i>ED</i><sub><i>i</i></sub>, the value of <i>E</i> is the value of the field
  that generated the event with the greatest timestamp. If two or more of the 
  outputOnly fields generated events with identical timestamps, results are undefined.</p>

<h3><a name="Prototypescopingrules"></a>
4.4.4.4 Prototype适用范围规则</h3>

<p>Prototype definitions appearing inside a prototype definition (<i>i.e.</i>, nested) 
  are local to the enclosing prototype. IS statements inside a nested prototype's 
  implementation may refer to the prototype declarations of the innermost prototype.</p>

<p>A PROTO statement establishes a DEF/USE name scope separate from the rest of 
  the scene and separate from any nested PROTO statements. Nodes given a name 
  by a DEF construct inside the prototype may not be referenced in a USE 
  construct outside of the prototype's scope. Nodes given a name by a DEF construct 
  outside the prototype scope may not be referenced in a USE construct inside 
  the prototype scope.</p>

<p>A prototype may be instantiated in a file anywhere after the completion of 
  the prototype definition. A prototype may not be instantiated inside its own 
  implementation <i>(i.e.</i>, recursive prototypes are illegal).</p>

<h2><a name="Externalprototypesemantics"></a>
4.4.5 外部原型</h2>

<h3><a name="ExternalprototypeIntro"></a>
4.4.5.1 介绍</h3>

<p>The EXTERNPROTO statement defines a new node type. It is equivalent to the 
  PROTO statement, with two exceptions. First, the implementation of the node 
  type is stored externally, either in an X3D file containing an appropriate PROTO 
  statement or using some other implementation-dependent mechanism. Second, default 
  values for fields are not given since the implementation will define appropriate 
  defaults.</p>

<h3><a name="EXTERNPROTOInterfaceSemantics"></a>4.4.5.2 EXTERNPROTO接口</h3>

<p>The semantics of the EXTERNPROTO are exactly the same as for a PROTO statement, 
  except that default field values are not specified locally. 
  In addition, events sent to an instance of an externally prototyped node may 
  be ignored until the implementation of the node is found.</p>

<p>Until the definition has been loaded, the browser shall determine the initial 
  value of inputOutput fields using the following rules (in order of precedence):</p>

<p><!--NOEDIT--> 
<ol type=a>
  <li>the user-defined value in the instantiation (if one is specified);</li> 
  <li>the default value for that field type.</li>
</ol>
<!--/NOEDIT--> 

<p>For outputOnly fields, the initial value on startup will be the default value for that 
  field type. During the loading of an EXTERNPROTO, if an initial value of an 
  outputOnly field is found, that value is applied to the field and no event is generated.</p>

<p>The names and types of the fields of the interface declaration shall be a subset of
  those defined in the implementation. Declaring a field with a non-matching name is an error,
  as is declaring a field with a matching name but a different type.</p>

<p>It is recommended that user-defined field names defined in EXTERNPROTO 
  interface statements follow the naming conventions described in <a href="#FieldSemantics">
  4.4.2.2 Field semantics</a>.</p>

<h3><a name="EXTERNPROTOURLSemantics"></a>4.4.5.3 EXTERNPROTO URL</h3>

<p>The string or strings specified after the interface declaration give the location 
  of the prototype's implementation. If multiple strings are specified, the browser 
  searches in the order of preference. For more information on URLs, see
<a href="components/networking.html">9 Networking component</a>.</p>

<p>If a URL in an EXTERNPROTO statement refers to an X3D file, the first PROTO 
  statement found in the X3D file (excluding EXTERNPROTOs) is used to define 
  the external prototype's definition. The name of that prototype does not need 
  to match the name given in the EXTERNPROTO statement. Results are undefined 
  if a URL in an EXTERNPROTO statement refers to a non-X3D file</p>

<p>To enable the creation of libraries of reusable PROTO definitions, browsers 
  shall recognize EXTERNPROTO URLs that end with "#<i>name</i>" to mean 
  the PROTO statement for "name" in the given X3D file. For example, a library 
  of standard materials might be stored in an X3D file called "materials.x3dv" 
  that looks like:</p>

<pre class="listing">#X3D V3.0 utf8
PROTO Gold   [] { Material { ... } }
PROTO Silver [] { Material { ... } }
     ...etc.
</pre>

<p>A material from this library could be used as follows:</p>

<pre class="listing">#X3D V3.0 utf8
EXTERNPROTO GoldFromLibrary [] "http://.../materials.x3dv#Gold"
   ...
 Shape {
   appearance Appearance { material GoldFromLibrary {} }
   geometry   ...
 }
 ...
</pre>

<h2><a name="ImportExportsemantics"></a>
4.4.6 导入/导出</h2>

<p>The IMPORT feature allows authors to incorporate content defined within Inline 
  nodes or created programmatically into the namespace of the containing file 
  for the purposes of event routing. In contrast with external prototyping (see 
  <a href="#Externalprototypesemantics">4.4.5 External prototype semantics</a>), which allows access to individual fields of nodes defined as prototypes 
  in external files, IMPORT provides access to all the fields of an externally 
  defined node with a single statement (see
<a href="components/networking.html#IMPORTStatement">9.2.5 IMPORT statement</a>).</p>

<p>Importing nodes from an Inlined file is accomplished with two statements: IMPORT 
  and EXPORT. The IMPORT statement is used in the containing file to define which 
  nodes of an Inline are to be incorporated into the containing file's namespace. 
  The EXPORT statement is used in the file being Inlined, to control access over 
  which nodes within a file are visible to other files (see
<a href="components/networking.html#EXPORTStatement">9.2.6 EXPORT statement</a>). 
EXPORT statements are not allowed in prototype declarations.</p>


<h2><a name="Runtimenamescope"></a>
4.4.7 Run-time name scope</h2>

<p>Each X3D browser defines a run-time name scope 
 that contains all of the root nodes currently contained by the scene graph 
 and all of the descendant nodes of the root nodes, with the exception of nodes 
 hidden inside another name scope. Prototypes establish a name scope and therefore 
 nodes inside prototype instances are hidden from the parent name scope.</p>

<p>Each Inline node or prototype instance also 
    defines a run-time name scope, consisting of all of the root nodes of the 
    file referred to by the inline node or all of the root nodes of the prototype 
    definition, restricted as above. Other nodes or extension mechanism may be 
    introduced which specify their own name scope.</p>

  <p>The IMPORT feature allows nodes defined within files referenced from
	<a href="components/networking.html#Inline">Inline</a><i> </i>nodes to be 
    incorporated into the run-time name scope of the containing scene graph. Once 
    an IMPORT statement has been encountered, the new name may be used exactly like 
    any other node name for the purposes of routing or programmatic access (<i>i.e.</i>, 
    may be used in ROUTE statements and accessed as a field from the Scene Access 
    Interface). Names imported from an Inline shall be explicitly declared as 
    exportable within the content of the inlined file, using the EXPORT statement; 
    only names exported using the EXPORT statement are available to be imported 
    into other run-time name scopes. The optional AS keyword allows a unique name 
    to be assigned to the imported node in order to avoid name conflicts in the 
    containing scene graph's run-time name scope.</p>

  <p>Nodes created dynamically (using the X3D Scene 
    Access Interface) are not part of any name scope, until they are added to 
    the scene graph, at which point they become part of the same name scope of 
    their parent node(s). A node may be part of more than one run-time name scope. 
    A node shall be removed from a name scope when it is removed from the scene 
    graph.</p>


<h2><a name="Eventmodel"></a>
4.4.8 事件模型</h2>

<h3><a name="Events"></a>
4.4.8.1 事件</h3>

  <p><i>Events</i> are the primary means of generating behaviors in the X3D 
  run-time 
    environment. Events are used throughout X3D: driving time-based animations; 
    handling object picking; detecting user movement and collision; changing the 
    scene graph hierarchy. The run-time environment manages the propagation of 
    events through the system according to a well-defined set of rules.</p>
<p>Nodes define input fields (<i>i.e.</i>, fields with inputOutput or inputOnly access)
    that trigger behavior. When a given event occurs, the node receives notification 
    and can potentially change internal state and the value of one or more of its fields.
	Nodes also define output fields (<i>i.e.</i>, fields with inputOutput or outputOnly access)
	that are sent upon  signal state changes or other occurrences within the node.
	Events sent to input fields and events sent by output fields are referred to
	collectively in ISO/IEC 19775 as <i>Events</i>.</p>

<h3><a name="Routes"></a>4.4.8.2 路由</h3>

<p><i>Routes</i> allows an author to declaratively 
    connect the output events of a node to input events of other nodes, providing 
    a way to implement complex behaviors without imperative programming. When 
    a routed output event is fired, the corresponding destination input event 
    receives notification and can process a response to that change. This processing 
    can change the state of the node, generate additional events, or change the 
    structure of the scene graph. Routes may be created declaratively in an X3D 
    file or programmatically via an SAI call.</p>

<p>Routes are 
    not nodes. The ROUTE statement is a construct for establishing event paths 
    between specified fields of nodes. ROUTE statements may either appear at the 
    top level of an X3D file or inside a node wherever fields may appear. It can 
    appear after its source or destination node and placing a ROUTE statement 
    within a node does not associate it with that node in any way. A ROUTE statement 
    does follow the name scoping rules as described in 
<a href="#Runtimenamescope">4.4.7 
    Run-time name scope</a>.</p>

  <p>The type of the destination field shall 
    be the same as the source type, unless a component or support level permits 
    an extension to this rule.</p>

  <p>Redundant routing is ignored. If an X3D file 
    repeats a routing path, the second and subsequent identical routes are ignored. 
    This also applies for routes created dynamically using the X3D SAI.</p>

  <p>Nodes created through the X3D prototyping mechanism give authors an opportunity 
    to create custom processing of incoming events. Events coming into a prototyped 
    node through an interface field can be routed to internal nodes for processing, 
    or routed to other interface fields for propagation outside the node. An author 
    can also add programmatic processing logic to an interface field using the 
    internal scripting support of the Script node.</p>

<h3><a name="ExecutionModel"></a>4.4.8.3 执行模型</h3>

<P>Once a sensor or Script has generated an <I>initial event</I>, the event is 
propagated from the field producing the event along any ROUTEs to other 
nodes. These other nodes may respond by generating additional events, continuing 
until all routes have been honoured. This process is called an <I>event 
cascade</I>. All events generated during a given event cascade are assigned the 
same timestamp as the initial event, since all are considered to happen 
instantaneously.</P>

<P>Some sensors generate multiple events simultaneously. Similarly, it is 
possible that asynchronously generated events could arrive at the identical time 
as one or more sensor generated event. In these cases, all events generated are 
part of the same initial event cascade and each event has the same 
timestamp. The order in which the events are applied is not considered 
significant. Conforming X3D worlds shall be able to accommodate simultaneous 
events in arbitrary order.</P>

<P>After all events of the initial event cascade are honored, post-event 
processing performs actions stimulated by the event cascade. The browser
shall perform the following sequence of actions during a single timestamp:</P>

<P>
<OL type="a">
  <LI>Update camera based on currently bound Viewpoint&#39;s position and 
	orientation.<LI>Evaluate input from sensors.<LI>Evalute routes.<LI>If any 
	events were generated from steps b and c, go to step b and continue.<LI>If 
	particle system evaluation is to take place, evaluate the particle systems 
	here.<LI>If physics model evaluation is to take place, evaluate the physics 
	model.</ol>

<p>For profiles that support <a href="components/scripting.html#Script">Script</a> nodes and the Scene Access Interface, the 
above order may have several intermediate steps. Details are described in
<a href="components/scripting.html">29 Scripting </a>and
<a href="references.html#[I19775_2]">2[I.19775-2]</a>.</p>

<P><A 
href="#f-ConceptualExecutionModel">Figure 
4.3</A> provides a conceptual illustration of the execution model.<br>
<a name="f-ConceptualExecutionModel"></a></P>
<CENTER>
<p>
<IMG src="../Images/ConceptualExecutionModel.png" alt="Conceptual execution model" width="572" height="258"></p>
<p class="FigureCaption">Figure 4.3 &#8212; Conceptual execution model</p>
</CENTER>
<P>Nodes that contain output events shall produce at most one event per field 
per timestamp. If a field is connected to another field via a ROUTE, an 
implementation shall send only one event per ROUTE per timestamp. This also 
applies to scripts where the rules for determining the appropriate action for 
sending output events are defined in <a href="components/scripting.html">29 Scripting component</a>.</P>

<h3><a name="Loops"></a>
4.4.8.4 循环</h3>

<p>Event cascades may contain <i>loops</i> where 
an event <i>E</i> is routed to a node that generates an event that eventually 
results in <i>E</i> being generated again. See <a href="#ExecutionModel">4.4.8.3 
Execution model</a>, for the loop breaking rule that limits each event to 
one event per timestamp. This rule shall also be used to break loops created 
by cyclic dependencies between different sensor nodes.</p>

<h3><a name="Fan-infan-out"></a>
4.4.8.5 扇入／出</h3>

<p><i>Fan-in</i> occurs when two or more routes have the same destination field. 
All events are considered to have been received simultaneously; therefore, the 
order in which they are processed is not considered relevant.</p>

<p><i>Fan-out</i> occurs when one field is the 
source for more than one route. This results in sending any event generated 
by the field along all routes. All events are considered to have been sent 
simultaneously; therefore, the order in which they are processed is not 
considered relevant.</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Components"></a>
4.5 组件</h1>

<h2><a name="ComponentsOverview"></a>4.5.1 概述</h2>

<p>An X3D component is a set of related functionality consisting of various X3D 
objects and services as described below. </p>

<p>Components are specified in this standard or may be defined elsewhere. This 
standard specifies a set of requirements which shall be satisfied for a 
component to be considered an X3D component. Components may be organized into 
support levels as provided by the component specification. The support levels 
are assigned an integer identifier starting with level 1 as the simplest support 
level. Higher numbered support levels (if specified) should incorporate all of 
the functionality of lower numbered support levels. Thus, the support levels 
support a hierarchy of functionality.</p>

<p>New components may be defined either through 
  creation of a new part to this International Standard or through registration. 
  Functionality may be added to an already defined component by amending the appropriate 
  part of this International Standard or through registration. Such new functionality 
  shall be in the form of one or more new levels that augment the functionality 
  already provided. Levels already defined shall not be subdivided. Each such 
  addition shall satisfy the requirements for component definition stated above.</p>

<h2><a name="DefiningComponents"></a>4.5.2 定义组件</h2>

<p>The following are the requirements for defining components:</p>

<ol type="a">
  <li> <span style="font-weight: 400">All node objects within a component shall 
	be derived, either directly or indirectly, from the <i>
	<a href="components/core.html#X3DNode">X3DNode</a></i> class.</span></li>
  <li> <span style="font-weight: 400">All field objects within a component shall 
    be derived from the<i> <a href="fieldsDef.html#X3DField">X3DField</a></i> or
	<i><a href="fieldsDef.html#X3DArrayField">X3DArrayField</a></i> classes.</span></li>
  <li> <span style="font-weight: 400">The names for nodes and fields shall follow 
    the naming semantics set forth in this standard including those for scoping.</span></li>
</ol>

<p>Several components are defined in this standard 
  as shown in the <a href="componentIndex.html">Component index</a>. These 
  components are defined in their respective parts of this International Standard. 
  In all cases, the X3D extension mechanism may be used to add new levels to the 
  components or may be used to define separate new components.</p>

<p>Each component definition is comprised of:</p>

<ol type="a" start="4">
  <li>a name for the component suitable for use in the COMPONENT statement;</li>
  <li><span style="font-weight: 400">one or more levels starting with Level 1;</span></li>
  <li> <span style="font-weight: 400">a list of prerequisites for the component 
    (each prerequisite consisting of a statement of which level in which other 
    component is required for support of the component being defined);</span></li>
  <li> <span style="font-weight: 400">a conceptual description of the functionality 
    being provided;</span></li>
  <li> <span style="font-weight: 400">a definition of nodes being provided with 
    an indication of in which level each node is; and</span></li>
  <li> <span style="font-weight: 400">a statement of conformance for the component.</span></li>
</ol>

<h2><a name="Basecomponents"></a>
4.5.3 基组件</h2>


<p>Components are specified in this standard or 
  may be defined elsewhere. See the <a href="componentIndex.html">Component 
  index</a> for a list of the components of X3D which have been formally 
accepted by the governing body.</p>


<p>Each component is presented by describing the functionality to be supported. 
This is followed by the specification of the abstract nodes of the component, if 
any. Following the abstract node specifications, the concrete nodes of the 
component are specified. Finally, the support levels are specified.</p>


<p>The support levels are specified in a table in which the first column 
presents the number of each support level. The second column specifies the 
prerequisite components that are required by the particular support level for 
the component being specified. Each new level is presented with its 
prerequisites in a separate row of the table. Subsequent rows until the next new 
level are used to specify node support for that level. The third column specifies the 
nodes and other features of the 
component that are to be supported, in whole or in part, by the indicated 
support level. The fourth column specifies any  constraints on the  particular 
feature or node for the indicated support level. For each support level i+1, all 
features of the previous support level shall also be supported.</p>


<p>In the second column, each prerequisite for a support level is listed by a 
component name and a support level within that component. These table entries 
indicate that, for the browser to claim support for that level of the component, 
the browser implementation shall also support the component and support
level(s) listed as a prerequisite. If there are no prerequisites, the word 
&quot;None&quot; is specified.</p>


<p>In the third column, abstract nodes introduced at that support level are 
listed first followed by the concrete nodes introduced at that support level.</p>


<p>In the fourth column, a listing of &quot;n/a&quot; means &quot;not applicable&quot;. When it is 
indicated that a field is &quot;optionally supported&quot;, an X3D browser is not required 
to support that field. If all fields of a node are to be entirely supported, the 
phrase &quot;Full support&quot; is used.</p>


<p><a href="#t-ExampleSupportLevelTable">Table 4.4</a> is an example of the format for a support level table:</p>

<div class="CenterDiv">
<p class="TableCaption">
<a name="t-ExampleSupportLevelTable"></a>Table 4.4 &#8212; Example support level table</p> 

   <table>
      <tr> 
        <th>Level</th>
        <th>Prerequisites</th>
        <th>Nodes/Features</th>
        <th>Support</th>
      </tr>
      <tr> 
        <td><b>1</b></td>
        <td>Core 1<br>
        Networking 2</td>
        <td></td>
      </tr>
      <tr>
        <td>&nbsp;</td>
        <td></td>
        <td><i>X3DTimeDependentNode</i> (abstract)</td>
        <td>n/a</td>
      </tr>
      <tr> 
        <td>&nbsp;</td>
        <td></td>
        <td>Node1Name</td>
        <td>fieldi optionally supported.</td>
      </tr>
      <tr> 
        <td>&nbsp;</td>
        <td>&nbsp;</td>
        <td>Node2Name</td>
        <td>All fields fully supported.</td>
      </tr>
      <tr> 
        <td><b>2</b></td>
        <td></td>
        <td></td>
        <td></td>
      </tr>
      <tr> 
        <td></td>
        <td></td>
        <td>Level 1 nodes</td>
        <td>All fields as supported by Level 
          1.</td>
      </tr>
      <tr> 
        <td></td>
        <td></td>
        <td>NodeName</td>
        <td>All fields fully supported.</td>
      </tr>
    </table>
</div>

<p>Any new components defined by amendment or in new parts of this International 
Standard shall specify their functionality using the same format.</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Profiles"></a>
4.6 Profile </h1>

<h2><a name="ProfilesOverview"></a>4.6.1 概述</h2>

<p>ISO/IEC 19775 supports the concept of profiles. 
  A profile is a named collection of functionality and requirements that shall 
  be supported in order for an implementation to conform to that profile. Profiles 
  are defined as a set of components and levels of each component as well as the 
  minimum support criteria for all of the objects contained within that set.</p>

<p>This part of ISO/IEC 19775 defines seven profiles satisfying varying 
sets of requirements:</p>

<ol type="a">
  <li>Core profile (see <a href="coreprofile.html">Annex A</a>)</li>
  <li>Interchange profile (see <a href="interchange.html">Annex B</a>)</li>
  <li>Interactive profile (see <a href="interactive.html">Annex C</a>)</li>
  <li>MPEG-4 interactive profile (see <a href="MPEG4interactive.html">Annex D</a>)</li>
  <li>Immersive profile (see <a href="immersive.html">Annex E</a>)</li>
  <li>Full profile (see <a href="fullProfile.html">Annex F</a>)</li>
	<li>CADInterchange profile (see <a href="CADInterchange.html">Annex H</a>)</li>
</ol>

<p>Each set of requirements is directed at supporting the needs of a particular 
constituency. Not all constituencies may be satisfied by the functionality 
represented by these  profiles. Therefore, this part of ISO/IEC 19775 
allows for defining additional profiles either through amendment to this part of 
this International Standard or by registration.</p>

<p>A system that conforms to a given profile supports 
  the full set of objects and capabilities defined for that profile.</p>

<h2><a name="Definingprofiles"></a>
4.6.2 定义Profile</h2>

<p>A profile definition consists of the following:</p>

<ol type="a">
  <li> a name for the profile suitable for use in the PROFILE statement;</li>
  <li> <span style="font-weight: 400">an introduction defining the purpose for 
    the profile;</span></li>
  <li> <span style="font-weight: 400">a list of the components and levels within 
    those components which comprise the profile;</span></li>
  <li> <span style="font-weight: 400">a statement of conformance criteria for 
    the profile;</span></li>
  <li> <span style="font-weight: 400">a table containing the node type set supported 
    by the profile stating the X3D File Limit and Minimum Browser Support for 
    each node type;</span></li>
  <li> <span style="font-weight: 400">a table of other limitations for the profile; 
	and</span></li>
  <li> <span style="font-weight: 400">any other information specific to the profile.</span></li>
</ol>

<h2><a name="RelationshipBetweenProfilesAndComponents"></a>4.6.3 Profile与组件的关系</h2>
<p>A profile consists of a collection of components at given support levels. A 
user may also supplement the predefined set of components for a given profile by 
specifying extra component 
statements (see <a href="components/core.html#COMPONENTStatement">7.2.5.4 COMPONENT statement</a>). If the user supplies additional 
component declarations in addition to the components and levels defined as part 
of the profile, the resultant components supported shall be the union of all 
components and levels requested. That is, a user cannot force a lower level of 
component conformance onto a profile by explicitly declaring the component with 
a lower level of support than that defined by the profile.</p>
<p>A profile definition shall be internally consistent. If a profile contains 
components that list prerequisites that are not covered by the component levels 
declared for that profile, the prerequisites shall not be automatically made 
available. Authors wishing to use these missing prerequisites shall explicitly 
declare the component and level required through the use of the COMPONENT 
statement.</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Supportlevels"></a>
4.7 支持应用级别</h1>

<p>The X3D specification may be supported at varying <i>Levels</i>, or qualities 
  of service. Any X3D component may designate a level of service by using a numbering 
  scheme in which higher-numbered levels denote increasing qualities of service. 
  A higher level of service may indicate any of the following:</p>

<ol type="a">
  <li> <span style="font-weight: 400">The presence (or absence) of features;</span></li>
  <li> <span style="font-weight: 400">Improved support for a particular feature;</span></li>
  <li> <span style="font-weight: 400">More rigorously defined semantics; or</span></li>
  <li> <span style="font-weight: 400">More stringent conformance requirements.</span></li>
</ol>

<p>Note that service levels between different features do not necessarily correspond. 
  For example, a profile may contain one component supported at level 2 and another 
  at level 1. Any profile may combine components defined at different service 
  levels, provided that the features interoperate properly, the behavior is deterministic 
  (within practical limits) and the conformance requirements for that profile 
  and components are well-defined.</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Dataencodings"></a>
4.8 数据编码</h1>

  <p>The X3D run-time architecture is independent of the data encoding format. 
   X3D content and applications can be authored in a variety of encodings, 
    including textual (XML and Classic VRML encodings) and binary, either compressed 
    or uncompressed. ISO/IEC 19775 contains 
    an abstract  encoding specification that defines the structure of the 
    X3D scene: hierarchical relationships among objects, initial values for objects, 
    and dataflow connections between objects. All concrete data encodings for 
    X3D shall conform to this abstract specification.</p>

<p>Browsers and generators may support any or all of the standard encoding formats, 
   depending on their application needs and the conformance requirements of a 
   specific component or profile.</p>

<p>X3D encodings are fully specified in the parts of
<a href="references.html#[I19776]">ISO/IEC 19776</a>.</p>

<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="SceneAccessInterface"></a>4.9 场景访问接口</h1>

<p>X3D provides a set of application programmer interfaces (APIs), called the 
Scene Access Interface (SAI), that defines run-time access to the scene. Using the 
SAI a developer may create and destroy 
  nodes, send events to nodes, create connections between nodes (<i>routes</i>), 
  read or set field values in nodes, traverse the scene graph, and control the 
  operations of the browser. Programmatic access may be <i>internal</i> (<i>i.e.</i>, used 
  to create customized elements within the scene graph) or <i>external</i> 
(<i>i.e.</i>, connecting 
  to program elements outside the scene such as in a host application such as a 
  web browser). Internal access is supported via a special node called a 
<a href="components/scripting.html#Script">Script</a><i> </i>
node. Script nodes allow developers to connect programming language functions 
and object classes to the scene graph. Fields of a script are automatically 
mapped to properties and methods of the object associated with that script. 
Script node code may generate events which are propagated back to the scene 
graph by the run-time environment. External access is supported through 
integration between the X3D run-time system and a variety of programming 
language run-time libraries.</p>

<p>The X3D SAI is specified as a set of language-independent services and bindings to
  several programming and scripting languages. A complete specification of the X3D SAI services and the component 
  model interfaces may be found in <a href="references.html#[I19775_2]">2.[I19775-2]</a>. The language bindings for the services defined in 
ISO/IEC 19775-2 are specified in <a href="references.html#[I19777]">2.[I19777]</a>. Internal programmatic access is enabled through the 
  Script node, described in <a href="components/scripting.html">29 Scripting 
  component</a>.</p>



<h1><img class="cube" src="../Images/cube.gif" alt="cube">
<a name="Componentprofilereg"></a>
4.10 组件及Profile注册</h1>

<p>This part of ISO/IEC 19775 allows new concepts to be defined by registration 
  of components, new levels within components, and profiles. Registration shall 
 not be used to modify any existing component, level of a component, or profile. 
  New functionality is registered using the established procedures of the <a href="http://jitc.fhu.disa.mil/nitf/graph_reg/welcome.htm">ISO 
  International Registration Authority for Graphical Items</a><sup><a href="#Footnote1">1)</a></sup>. 
  These procedures require the proposer to supply all information for a new registered 
  item except for the level number. The level number (if applicable) is 
  assigned and managed by the ISO International Registration Authority for Graphical 
  Items. Registration shall be according to the procedures in 
<a href="references.html#[I9973]">ISO/IEC 9973</a>.</p>
<p class="Footnote"><sup><a name="Footnote1"></a>1)</sup>At the time this International Standard 
  was published, the 
<a href="http://jitc.fhu.disa.mil/nitf/graph_reg/welcome.htm">ISO International Registration Authority for Graphical Items</a> was the United 
  States National Imagery and Mapping Agency (NIMA). The mailing address was: 
  Registration Authority, National Imagery and Mapping Agency, c/o Joint Interoperability 
  Test Command, Building 57305, Room 263A, Fort Huachuca, Arizona 85613-7020. 
  USA.</p>

<img class="x3dbar" src="../Images/x3dbar.png" alt="--- X3D separator bar ---" width="430" height="23" />

</body>
</html>